1. Technical Field
The present invention generally relates to processors and more particularly to methods for configuring processor architecture for compatibility with software.
2. Description of the Related Art
Computing devices today are capable of performing many tasks. Conventional computing devices can execute various types of software products, and include the capability of executing software designed to run on older hardware, such as an older central processing unit (CPU). Computing devices are managed by and execute the software products via an operating system (O/S) that is running on the computing device. The O/S manages the hardware and software resources of the system and provides a stable, consistent way for applications to interact with the computing device's hardware.
Typically, when a program written for a given level of a processor architecture is run on a processor conforming to a later level of the architecture that defines more instructions or other facilities, errors may occur due to the inadvertent usage of the new instructions or facilities. For example, a program written for processor A, conforming to architecture A, contains latent “bugs” such as not setting reserved fields in instructions to “0s” as required by the architecture. When the program is run on processor A, errors may not occur because the processor ignores these fields. If architecture B is then developed and the architecture defines these previously reserved fields, then processor B (conforming to architecture B) no longer ignores these fields, and serious errors may occur when the program executes on processor B.
Unfortunately, in the present state of the art, the only way to solve this problem is to test the program on a processor conforming to the newer level of the architecture to discover any hidden errors. The errors can then be corrected and the program redistributed to all users. This is prohibitively expensive in most cases and sometimes impossible if the program cannot be modified due to lack of support or the unavailability of the source code.
Additionally, a problem may occur when new programs are being written for processor B. For example, the program will utilize the new facilities of processor B, but needs to ensure the program will execute correctly on processor A, which does not have the new facilities. Currently, the only method of ensuring that there are not any latent bugs that cause the program to function improperly on processor A is to test the program on processor A. This method requires processor A be available, and the method may not present a problem if the program is being designed to run on processors conforming to only two levels of the architecture. However, when the program is being designed to run on several previous levels of the architecture, the requirement to obtain samples of processors conforming to each old level of architecture becomes excessively burdensome.
Another problem occurs in situations in which an executing program is to be migrated among a set of processors, each of which may conform to a different level of the architecture. Migration in this context means that the execution state of the program is transferred from one processor to another while the program is still running. A form of program migration is logical partition migration, which is migration in situations where the resources of a single computer are shared by an independent set of logical partitions. Each partition is configured to run at the architecture capabilities of a given architecture level. During partition migration, where an executing logical partition is migrated from a source computer system to a target computer system, the source and target computer systems may have processors that conform to different levels of the processor architecture. Since the program may be designed for a particular level of the architecture, the set of processors to which migration can occur is limited to those processors that conform to the level of the architecture for which the program was designed This restriction can limit the migration possibilities and correspondingly limit the versatility of program migration.
Given the above issues, it is clear that an adequate method for selecting the architecture level to which a processor appears to conform has eluded those skilled in the art, until now. Since it is important for programs to be executable on enhanced (or newer or different) levels of a processor architecture, a mechanism is needed to ensure that if the program executes correctly on a processor conforming to one level of the architecture the program will then run on processors conforming to all subsequent levels of the architecture without being modified, even if the program contains latent bugs such as previously described. Additionally, a mechanism is needed that ensures the program will execute correctly on older processors without requiring the older processors be physically available for testing thereof. Furthermore, a scheme is needed that allows a program to be migrated among all processors regardless of the architecture level supported by the set of processors. Such a scheme will also allow the live migration of a program between two computer systems that have processors that conform to different levels of the architecture.